git rebase
ひとりGitで仮想プロジェクトする
sologit/user1
sologit/user2
sologit/user3
↑こんなフォルダ掘って、ターミナル立ち上げて1人n役でバリバリ作業する演習
知りたい
masterの最新を取ってくる、developに機能をリリースする ← これが merge 時よりも簡単になるんですか？
bra1 でつくってきた n コミットを、1コミットとして merge することはできますか？
同上、rebase はできますか？
merge や rebase と local remote の関係
pull、fetch、merge の関係
職場で merge より rebase が良いと教えてもらった
結論part2
mergeをやめてrebaseを使うべき理由は（机上レベルだと）わからんかった
コミットログを綺麗にするべき、は同意だが、merge or rebase とは話題が違う
結論
rebaseの良さ（机上学習だと）わからんです
むしろ間違えて絶交操作しちゃうのが怖いです
コミットログ別に汚くても良くないっすか？
きりのいいコミットはタグ付けすればいいのでは？
というか履歴を改変するという発想がよくわからん
議事メモやチャットとかも消したりはしないやんいや、するする
文章変えるくらいのフットワークで履歴も（読みやすく）変える ← こういうこと？
sta.iconでしょうね
sta.iconたぶん複数人開発初心者でピンと来てない
「mergeだけじゃしんどいンゴ」経験した人だけが理解できる境地なんだろう
机上勉強と手元で一人練習してるだけじゃわかんね
僕: merge 派 + feature ブランチも remote にガンガン上げて見せるマン
先輩: rebase + master/develop ブランチ以外はローカルだけで良い
なんか rebase 使うと常に最新のをかんたんに取り込めるからマージで苦労しない、みたいなこと言ってた
sta.icon何回も理解挫折してる（すぐ忘れる）から、今度こそはしっかり理解したい
mergeは？
code:git
git co master
git merge bra1
つまり merge from
merge from A to Checked out branch
チェックアウト中のブランチをいじる
「お前を俺に取り込んでやるぜ」
Q: fast forward？
merge-to が分岐点になっている場合
単に merge-to から merge-from に進めばいいだけ
Q: merge commit？
merge-to が分岐点になっていない場合
merge-to の祖先 to's ancestors と、merge-from の祖先 from's ancestors
共通している最初の祖先を common ancestor とする
このようにたどれば良い
merge-to → common ancestor → merge-from
詳しい処理はわからんが、merge-to 側の変更と merge-from 側の変更を両方取り入れていく
ox
x 衝突することがある
x common ancestor から merge-from までのコミット数だけコミットが増える
o わかりやすい
rebaseは？
code:git
git co bra1
git rebase master
つまり rebase to A
rebase from Checked out branch to A
チェックアウト中のブランチはいじらない
「俺をお前にねじ込んでやるぜ」
「俺がここまで行ってきた変更を順にお前に適用してやるぜ」
Q:どう動く？
rebase-from と rebase-to の共通の祖先 common ancestor
1 common ancestor から rebase-from までのコミット(diff)を全部覚えておく
2 rebase-to に移動
3 覚えてた1を順に適用する
Q: rebase だけで rebase-to も更新される？
されない
rebase の後、merge(fast forward)が必要
ox
o コミットログが fast-forward になってスッキリする
～の土台や基準を新しくする、的な意味
公開リポジトリにプッシュしたコミットをリベースしてはいけない
こっから全然ピンと来ない
rebase を行うと、今チェックアウトしているコミットが消える
仮にbra1が既にリモートに存在しているとする
1 Aさんがbra1を取得して作業している
2 Bさんもbra1で作業しているが、rebaseした
3 Bさんはpushまでした
sta.iconここからどうなる？
sta.icon例見てもよくわからんな
なんか rebase 使うと常に最新のをかんたんに取り込めるからマージで苦労しない、みたいなこと言ってた
これを咀嚼する
ダメだ、わからん
github依存が強すぎて、（多人数開発で）ローカルでmasterブランチを編集してpushする世界観に共感できない…
これがピンと来ない
ローカルでmasterいじってpushする以外の方法がある？
rebaseでも最後に git co master からの merge するやん
わからん
Q: mergeするとコミットログが汚くなるってどういうこと？
https://gyazo.com/3ec095574b3a749363adca080c53cb8b
一本じゃん（一覧で表示できてるじゃん）
汚いログどっかないだろうか
https://gyazo.com/e0cfb0ff31b21286ccda2fb1a81fd8f2
一本じゃん
mergeされた後にコミットが10個増えたとして、この10個の出所（ブランチ）が違うってだけで、一本で読めるじゃん
出所が違うのに一本に混ざってるから読みづらいってこと？
わかんね
Q:rebaseだとnコミットを1コミットにできるって本当？
Ans: rebase時の動作モードをsquashにする
rebaseの内部動作モードにeditとsquashがあるらしい
「squash(=潰す)」を選択すると、そのコミットを他のコミットにまとめることができます。修正などの履歴として残す必要のないコミットを Squash します。
rebase -i でエディタ上で「このコミットは squesh する」みたいな指定をしていく感じ